Gdk-Win32 uses GetClientRect() internally to query the surfaces coordinates,
but this API may fail in some transient contexts (observed when iconifying
a maximized window).
Check if the rect area is null, and don't update the surface position in
that case. This will keep the current surface size, until Win32 notifies
the new valid window state later.
This prevents using a nulled next_layout for toplevel size computation,
which would break widgets allocation once notified on gtk side.
Matthias Clasen [Sun, 22 Oct 2023 20:19:31 +0000 (16:19 -0400)]
gsk: Restore bigendian support
Restore the bigendian support that was lost in b0e26873f66a8f52,
by just not using GL_BGRA with GLES on bigendian. Should be a
very rare combination, but still.
Matthias Clasen [Fri, 20 Oct 2023 01:41:44 +0000 (21:41 -0400)]
gsk: Use has_bgra in more places
The glyph and icon libaries were also checking for GLES to
decide if data needs to be transformed from BGRA to RGBA.
Use the new has_bgra getter instead.
This will probably break on bigendian, because the
GL_BGRA + GL_UNSIGNED_BYTE combination is not equivalent
to the cairo format on bigendian, but this was already
broken for the gl format information that we get from
gdk_memory_format_gl_format.
This makes the CI yaml identical to the one in main, which changes
two things:
- modernize workflow configuration
- use a new macOS runner for macOS CI
Sergey Bugaev [Tue, 17 Oct 2023 08:40:51 +0000 (11:40 +0300)]
Stop using enums in bitfields
The C standard does not specify whether the underlying type of an enum
is signed or unsigned, and until C23 there was no way to control this
explicitly. GCC appears to make enums unsigned unless there is a
negative value among cases of the enum, in which case it becomes signed.
MSCV appears to make enums signed by default.
A bitfield of an enum type (which is not specificied in the C standard
either) behaves as if it was an instance of a numeric type with a
reduced value range. Specifically, a 'signed int val : 2;' bitfield will
have the possible values of -2, -1, 0, and 1, with the usual wraparound
behavior for the values that don't fit (although this too is
implementation-defined).
and then assign bar.foo = GTK_TWO and read it back, it will have the
expected value of 2 (aka GTK_TWO) on GCC, but a value of -2 (not
matching any of the enum variants) on MSVC.
There does not seem to be any way to influence signedness of an enum
prior to C23, nor is there a 'unsigned GtkFoo foo : 2;' syntax. The only
remaining options seems to be never using enums in bitfields, which is
what this change implements.
In practice, this fixes GdkPipeIOStream crashing with an assertion when
trying to copy-paste in-app in MSVC builds on GTK.
The portal printoperation inmplementation
relies on the file printbackend to be available.
If it isn't, we should report a proper error
status insetad of running into assertions deep
inside the printoperation code.
gsk/gl: remove TypeNode conformity checking for renderjob
We don't need to be calling type node conformity checking from the tight
loop of the renderjob. Hoist that into the private header and use that
intead through via the Class pointer.
Anything that includes gskrendernodeprivate.h will get an alternate form
of ref/unref for render nodes which does not need to do type checking on
the parameter. We can expect that things are correct within GTK itself and
this saves excessive amounts of TypeNode conformities checking.
Let's assert that we schedule the idle callback exactly once.
These assertions are not perfect because if the callback executes before
we schedule it, then the assertion itself would be a use-after-free,
since I'm using the PrinterFinder to track whether the callback that
frees it has been scheduled. But in practice when using loupe's print
dialog, I was noticing the callback scheduled twice before it was
executed. The assertion would have caught this problem.
printoperation: fix another case where operation may complete twice
This is a little tricky. At first, I thought we had a codepath where we
fail to schedule the idle that completes the print operation: if we take
the gtk_print_backend_printer_list_is_done path for each printer
backend, then printer_list_done_cb() is never executed and we never
schedule the idle. But in fact, in this case, then backends == NULL at
the bottom of find_printer(), and we'll schedule the idle there, so it's
OK. Except it's not really OK, because we'll schedule it even if a
printer was already found, resulting in the callback completing twice
and a double free.
Simplify this. Schedule the idle in find_printer() only if there are
*initially* no backends, not also if all backends are immediately ready
and already removed from consideration. Instead, always call
printer_list_done_cb() for every backend in find_printer_init(). After
the previous commit, printer_list_done_cb() will schedule the idle when
appropriate.
printer_list_done_cb() additionally disconnects signals that we did not
connect in this codepath, but it does so using
g_signal_handlers_disconnect_by_func, which is harmless. Otherwise, the
only extra work it's doing is scheduling the idle, and that's exactly
what find_printer_init() is missing.
printoperation: fix case where operation may complete multiple twice
If we are the final backend, then after removing ourselves there is no
backend remaining. We will schedule the idle even if it has already been
scheduled. This idle is required to run exactly once and executing it
twices results in a double free that crashes loupe when printing. It
also causes the user callback to execute twice, which could cause
similar problems.
Like the previous change, this uses GdkArrayImpl instead of GArray for
tracking modelview changes. This is less important than clip tracking
simple due to being used less, but it keeps the implementation synchronous
with the Clip tracking code.
We can end up spending a lot of time in g_array_maybe_expand() through the
use of g_array_set_size() for clip tracking. That is somewhat due to the
simple nature of GArray being size-dynamic. Instead, we can use
GdkArrayImpl and let the compiler do what it does best to elide some
work and hoist other work into the calling function.
This also fixes a potential UAF in gsk_gl_render_job_push_contained_clip().
When getting a colorized texture we're downloading the texture as a
Cairo surface, and then feeding it to another texture, but we never drop
the reference of the new surface.
Carlos Garnacho [Mon, 18 Sep 2023 20:04:32 +0000 (22:04 +0200)]
gdk/wayland: Use toplevel surface for activation
At the moment of launching/activating an application, the
keyboard focus may be on a transient surface that quickly
disappears after activation. If this happens, and the
compositor handles surface destruction before the activated
application gets to reply, the activation request may be
deemed outdated, and the "demands attention" paths be taken.
Peek the toplevel from the focus surface, as that has larger
guarantees to remain valid for the whole duration of the
operation.
Carlos Garnacho [Mon, 18 Sep 2023 17:42:41 +0000 (19:42 +0200)]
gtkwindow: Pick a suitable widget to continue the implicit grab
When a widget in the GtkPointerFocus stack becomes insensitive, we've
so far broken the implicit grab entirely. This has the side effect of
breaking accounting of the active state on the widgets that are
ancestors of the widget that became insensitive.
The easiest, and most consistent thing to do (i.e. giving widgets
in the GtkPointerFocus stack certain level of isolation wrt state
changes in other widgets) is to transfer the implicit grab to the
topmost actor of the GtkPointerFocus stack that can keep handling
events.
This fixes the unbalanced accounting of active state on ancestors
of widgets becoming insensitive, and avoids thorny questions about
how to handle implicit active state with broken implicit grabs.
Carlos Garnacho [Mon, 18 Sep 2023 17:40:05 +0000 (19:40 +0200)]
gtkwindow: Clear active state on sensitiveness changes
When altering the broken implicit grab due to sensitiveness changes,
also ensure to clear the active state from the affected actors. This
fixes unbalanced implicit active state accounting on the widgets going
insensitive.
Sergey Bugaev [Fri, 25 Aug 2023 16:13:43 +0000 (19:13 +0300)]
colorbutton, fontbutton: Propagate focus-on-click to inner buttons
These widgets wrap a GtkButton internally. Make it possible to prevent
the inner button from grabbing focus on click by propagating the value
of the focus-on-click property from the widget to the inner button.
Benjamin Otte [Mon, 18 Sep 2023 05:48:10 +0000 (07:48 +0200)]
gsk: Fix clipping error when drawing shadows
When shadows were offset - in particular when offset so the original
source was out of bounds of the result - the drawing code would create a
pattern for it that didn't include enough of it to compose a shadow.
Fix that by not creating those patterns anymore, but instead drawing the
source (potentially multiple times) at the required offsets.
While that does more drawing, it simplifies the shadow node draw code,
and that's the primary goal of the Cairo rendering.
This function is deprecated, but we should still document it properly.
It appends, not prepends. This is clear enough from its implementation,
but also we have practical experience with WebKit in:
https://github.com/WebKit/WebKit/pull/8663
Matthias prefers to avoid the prepend, append, start, and end
terminology altogether.
Benjamin Otte [Thu, 7 Sep 2023 14:02:09 +0000 (16:02 +0200)]
rendernode: Fix Cairo rendering of repeating gradients
Cairo and the GL renderer have a different idea of how to handle
transitioning of colors outside the defined range.
Consider these stops:
black 50%, white 50%
What color is at 0%?
Cairo would transition between the last and first stop, ie it'd do a
white-to-black transition and end up at rgb(0.5,0.5,0.5) at 0%.
GL would behave as it would for non-repeating gradients and use black
for the range [0%..50%] and white for [50%..100%].
The web would rescale the range so the first stop would be at 0% and
the last stop would be at 100%, so this gradient would be illegal.
Considering that it's possible for code to transition between the
different behaviors by adding explicit stops at 0%/100%, I could choose
any method.
So I chose the simplest one, which is what the GL renderer does and
which treats repeating and non-repeating gradients the same.
If the entry has icons, we may end up increasing our minimum and natural
height compared to the values the text child returned. In that case, we
should also adjust the baseline values to account for the text being
shifted down.
centerlayout: Fix measuring in presence of baselines
The measure logic (unlike the allocation logic) was enforcing strict
baseline alignment of child widgets even if no child widget had valign
set to baseline. This was causing GtkCenterLayout to request more size
than it actually needed.
Instead, bring the logic closer to that of GtkBoxLayout by introducing
explicit have_baseline and align_baseline variables. We track and report
baseline if have_baseline gets set, but it only affects our reported
minimum and natural sizes if align_baseline ends up set, which happens
if there's a child widget that has valign set to either one of the two
baseline values, and itself reports a valid baseline.
Matthias Clasen [Tue, 29 Aug 2023 16:18:49 +0000 (12:18 -0400)]
composetable: Warn for things we can't handle
The compose table stores the keyvals to match against
in a guint16 array, so it can't handle directly encoded
Unicode codepoints (which have a high bit set). Warn
if we encounter those.
projects / gtk4.git / log